Subject: DLSw Partner Discovery and Resource Advertisement Proposal

From: [email-masked]
Date: Fri, 1 Nov 96 14:36:57 EST

Jon Houghton       IBM Corporation                        Oct 1996

 DLSw Partner Discovery and Resource Advertisement

 1.0 Background
 2.0 Intent
 3.0 Scope
 4.0 DLSw Partner Discovery Frames
 5.0 DLSw Partner Discovery Details
 6.0 Capabilities Exchange Overview
 7.0 Resource Advertisement Details
 8.0 Basic Discovery / Resource Advertisement flows
 9.0 Issues Not Incorporated

 1.0 Background

     This proposal describes two functions:

 1) The ability to use the multicast/unicast DLSw capabilities to discover
 all potential DLSw partners without having to configure them.

 2) The adaptation of the resource advertisement capabilities of the AIW
 standard for Data Link Switching (DLSw) in RFC 1795 to the DLSw Multicast
 Protocol Enhancements proposal being considered by the Data Link Switching RIG.

 2.0 Intent

     This proposal defines a set of enhancements to RFC 1795.  These
 enhancements are designed to be fully backward compatible with existing
 RFC 1795 implementations.  Once completed and approved within the AIW,
 it is the intent of the DLSw body to submit these enhancements along with
 any other approved enhancements to the IETF in the form of a set of optional
 enhancements to RFC 1795 (version 1.2).

 3.0 Scope

     This proposal deals with two issues introduced by the proposed DLSw
 multicast protocol enhancements.

     The term broadcast search is used to refer to explorer or datagram
 SSP messages sent to all DLSw partners.  The term directed search is used
 to refer to explorer or datagram SSP messages sent to one or more specific
 DLSw partners (not to all).

 3.1 Discovery of all DLSw Partners

     RFC 1795 assumes that a DLSw has a configured list of all of its
 DLSw partners.  At a minimum, for a DLSw TCP session to be established,
 one of the DLSw partners must have the other partner configured.

     The DLSw multicast protocol enhancement proposal introduces the
 ability for explorer traffic to flow between DLSw partners and a subsequent
 TCP session established without either partner having prior knowledge
 of the other DLSw partner's IP address.

     The problem is that there is no architected means by which a DLSw
 can discover all of its partners without using explorer traffic.

     One requirement for being able to do this is to help solve the
 problem of limiting the scope of broadcast searches in the multicast
 environment.

 3.2 Limiting the Scope of Broadcast Searches

     RFC 1795 specifies five capabilities exchange control vectors whose
 purpose is to send directed searches to a limited set of partners instead
 of sending a broadcast search to all partners, independent of what has
 been cached.  The five control vectors are:
  - supported sap list
  - MAC address exclusivity
  - MAC address list
  - NetBIOS name exclusivity
  - NetBIOS name list.

     In the DLSw multicast protocol enhancements proposal, broadcast searches
 will occur before a TCP connection is established and capabilities exchanged.
 This negates the above capabilities control vectors and forces broadcast
 searches in all cases in which there is no cached information.

     This presents problems in the following environments.

 3.2.1 Existing RFC 1795 Implementations

     Any current RFC 1795 implementation that uses sap lists, MAC address
 lists, or NetBIOS name lists to limit the number of broadcast searches
 and the amount of WAN traffic needs to be able to provide the same
 functions once the multicast function is implemented.

 3.2.2 Indicating NetBIOS Support

     The RFC 1795 supported sap list capabilities control vector is used
 to indicate whether a particular DLSw partner supports NetBIOS traffic.
 This information should be available to DLSw partners prior to multicast
 searches as well.

 3.2.3 Reducing Need for Broadcast Searches

     SAP lists, MAC address lists, and NetBIOS name lists provide DLSw
 implementations and the customer the ability to control which traffic
 is forwarded by DLSw and the set of partners to which it is forwarded.
 They provide the customer with the ability to send directed searches
 instead of broadcast searches.

     If it is determined that a broadcast search is necessary (by the
 implementation or the customer), then the multicast search is the
 most efficient method.  But, it may not be more efficient than the
 directed searches.  For example, it may be advantageous to control
 the traffic sent over a dial circuit with directed searches.

 4.0 DLSw Partner Discovery Frames

     To provide the ability for a DLSw to discover all of its DLSw
 partners (ones reading one or more of the same multicast IP addresses
 that the DLSw is writing to) using multicast/unicast services, two
 new DLSw UDP frames have been created.

  - AreYouThere
  - IAmHere

 4.1 AreYouThere DLSw UDP frame format

     The AreYouThere frame is an optional frame.  This frame is sent via
 UDP multicast to all configured DLSw write multicast IP addresses.
 This frame can also be sent via unicast to a particular DLSw box's IP
 address to determine if the particular DLSw is still available or whether
 its capabilities have changed.

     The format of the new AreYouThere frame is

   Common DLSw UDP OUI header:
    +----------------------------------+----------------------------------+
    | (00) Version Number (0x32)       | (01) Header Length (0x08)        |
    +----------------------------------+----------------------------------+
    | (02) Message Length (0x0000)                                        |
    +----------------------------------+----------------------------------+
    | (04) OUI (0x000000)                                                 |
    +----------------------------------+----------------------------------+
    |                                  | (07) Message Type (0x01)         |
    +----------------------------------+----------------------------------+

   AreYouThere Common Information:
   GDS ID Vector:
    +----------------------------------+----------------------------------+
    | (08) GDS length (4 + sum of length of all CVs)                      |
    +----------------------------------+----------------------------------+
    | (0a) AreYouThere GDS ID (0x???? - e.g., 0x1523)                     |
    +----------------------------------+----------------------------------+

   CapexCorr CV (required):
    +----------------------------------+----------------------------------+
    | (0c) CapexCorr CV len (0x06)     | (0d) CapexCorr CV ID (0x8D)      |
    +----------------------------------+----------------------------------+
    | (0e) CapexCorr value                                                |
    +----------------------------------+----------------------------------+
    |                                                                     |
    +----------------------------------+----------------------------------+

   VendorContext CV (optional and repeatable):
    +----------------------------------+----------------------------------+
    | (12) VendorContext CV len (0x05) | (13) VendorContext CV ID (0x8B)  |
    +----------------------------------+----------------------------------+
    | (14) Vendor OUI                                                     |
    +----------------------------------+----------------------------------+
    |                                  |
    +----------------------------------+

   VendorSpecific CVs (optional):
                                       +----------------------------------+
                                       | (17) ----                        |
                                       +----------------------------------+
                                       :
                                       :
    +----------------------------------+----------------------------------+
    |                                                                     |
    +----------------------------------+----------------------------------+

 Version Number is set to 0x32 for all DLSw UDP OUI frames that comply with
 RFC 1795 and enhancements.

 Header Length is set to the length of the standard part of the DLSw UDP OUI
 frame format (8 bytes).

 Message Length is set to the length of the AreYouThere GDS frame (the same
 value as is in the GDS length field).

 The OUI field is set to all zeroes to indicate a DLSw UDP OUI format frame
 that is architected and approved by the AIW as a standard frame format.

 Message type is set to 0x01 - the value for a Discovery/Resource Advertisement
 UDP frames.

 The CapexCorr CV contains the capex correlator field.  The correlator
 is associated with a level of DLSw capabilities information.  This
 correlator must initially be set to some random value (perhaps date/time).
 Each time the DLSw configuration (capabilities) changes, this correlator
 must change.  This signifies to the receiver of this frame that it
 could send a GetCapexInfo frame to obtain the new capabilities.

 The VendorContext CV is identical to that in the CapabilitiesRequest
 SSP message.  It is used to correlate the VendorSpecific CVs that follow
 to a particular vendor.  This CV is only needed if VendorSpecific CVs
 are sent in the frame.  This CV is repeatable.

 4.2 IAmHere DLSw UDP frame format

     The IAmHere frame is a mandatory frame.  This frame must be
 sent via UDP unicast in response to a received AreYouThere frame.
 The IAmHere frame can also be sent via UDP unicast or multicast when
 the DLSw is starting up or changing capabilities, but this is not
 required.

     The format of the new IAmHere frame is

   Common DLSw UDP OUI header:
    +----------------------------------+----------------------------------+
    | (00) Version Number (0x32)       | (01) Header Length (0x10)        |
    +----------------------------------+----------------------------------+
    | (02) Message Length (0x0000)                                        |
    +----------------------------------+----------------------------------+
    | (04) OUI (0x000000)                                                 |
    +----------------------------------+----------------------------------+
    |                                  | (07) Message Type (0x01)         |
    +----------------------------------+----------------------------------+

   IAmHere Common Information:
   GDS ID Vector:
    +----------------------------------+----------------------------------+
    | (08) GDS length (4 + sum of length of all CVs)                      |
    +----------------------------------+----------------------------------+
    | (0a) IAmHere GDS ID (0x???? - e.g., 0x1524)                         |
    +----------------------------------+----------------------------------+

   CapexCorr CV (required):
    +----------------------------------+----------------------------------+
    | (0c) CapexCorr CV len (0x06)     | (0d) CapexCorr CV ID (0x8D)      |
    +----------------------------------+----------------------------------+
    | (0e) CapexCorr value                                                |
    +----------------------------------+----------------------------------+
    |                                                                     |
    +----------------------------------+----------------------------------+

   MulticastIP@ CV (required if in response to an AreYouThere):
    +----------------------------------+----------------------------------+
    | (12) MulticastIP@ CV len (0x06)  | (13) MulticastIP@ CV ID (0x8E)   |
    +----------------------------------+----------------------------------+
    | (14) Multicast IP address                                           |
    +----------------------------------+----------------------------------+
    |                                                                     |
    +----------------------------------+----------------------------------+

   VendorContext CV (optional and repeatable):
    +----------------------------------+----------------------------------+
    | (18) VendorContext CV len (0x05) | (19) VendorContext CV ID (0x8B)  |
    +----------------------------------+----------------------------------+
    | (1a) Vendor OUI                                                     |
    +----------------------------------+----------------------------------+
    |                                  |
    +----------------------------------+

   VendorSpecific CVs (optional):
                                       +----------------------------------+
                                       | (1d) ----                        |
                                       +----------------------------------+
                                       :
                                       :
    +----------------------------------+----------------------------------+
    |                                                                     |
    +----------------------------------+----------------------------------+

 Version Number is set to 0x32 for all DLSw UDP OUI frames that comply with
 RFC 1795 and enhancements.

 Header Length is set to the length of the standard part of the DLSw UDP OUI
 frame format (8 bytes).

 Message Length is set to the length of the IAmHere GDS frame (the same
 value as is in the GDS length field).

 The OUI field is set to all zeroes to indicate a DLSw UDP OUI format frame
 that is architected and approved by the AIW as a standard frame format.

 Message type is set to 0x01 - the value for a Discovery/Resource Advertisement
 UDP frames.

 The CapexCorr CV contains the capex correlator field.  The correlator
 is associated with a level of DLSw capabilities information.  This
 correlator must initially be set to some random value (perhaps date/time).
 Each time the DLSw configuration (capabilities) changes, this correlator
 must change.  This signifies to the receiver of this frame that it
 could send a GetCapexInfo frame to obtain the new capabilities.

 The MulticastIP@ CV contains the multicast IP address field.  If the
 IAmHere frame is sent in response to an AreYouThere frame, the
 MulticastIP@ CV is required.  The multicast IP address field must
 be set to the multicast IP address that the AreYouThere frame was
 received on.  This allows the receiver of the IAmHere frame to
 correlate an IP address with the multicast IP address that it
 is receiving on.

 The VendorContext CV is identical to that in the CapabilitiesRequest
 SSP message.  It is used to correlate the VendorSpecific CVs that follow
 to a particular vendor.  This CV is only needed if VendorSpecific CVs
 are sent in the frame.  This CV is repeatable.

 5.0 DLSw Partner Discovery Details

 5.1 Overview

     Each v1r2 compliant DLSw has two obligations with respect to DLSw
 partner discovery:

 1) Maintain an accurate capex correlator field.  This field should remain
 the same until the capabilities change or the DLSw function restarts - then
 the value must change to indicate a capabilities change.

 2) A DLSw must respond to an AreYouThere frame with an IAmHere frame.

     A DLSw is NOT obligated to do any of the following:

 1) Send an AreYouThere frame.

 2) Send an unsolicited IAmHere frame.

 3) Maintain any information about DLSw partners having sent AreYouThere
 or IAmHere frames.

     Since the AreYouThere and IAmHere frames are not in the SSP message
 format, they may not be sent as TCP frames.

 6.0 Capabilities Exchange Overview

     The resource advertisement enhancements involve simple modifications
 to the existing RFC 1795 capabilities exchange and changes in how the
 Capabilities Exchanges are initiated and sent.  Following are overviews
 of the key enhancements.

     To make resource advertisement possible, one new frame is created
 and the use of the existing Capabilities Exchange Request is modified.
 The new frame is:

  - GetCapexInfo.

    In addition, there are minor changes to the Capabilities Exchange
 Request SSP message:

  - The message can be sent via unicast UDP.
  - A new GDS ID is used to signify a UDP Capabilities Exchange Request.
  - A new control vector is added - Capex Correlator CV.

 6.1 GetCapexInfo DLSw UDP frame format

     The GetCapexInfo frame is an optional frame.  This frame is sent
 via unicast to a DLSw partner's individual IP address.  This frame might
 be sent when a partner is learned for the first time, or an IAmHere frame
 is received from the partner with a new Capex Correlator.

     The format of the new GetCapexInfo frame is

   Common DLSw UDP OUI header:
    +----------------------------------+----------------------------------+
    | (00) Version Number (0x32)       | (01) Header Length (0x08)        |
    +----------------------------------+----------------------------------+
    | (02) Message Length (0x0000)                                        |
    +----------------------------------+----------------------------------+
    | (04) OUI (0x000000)                                                 |
    +----------------------------------+----------------------------------+
    |                                  | (07) Message Type (0x01)         |
    +----------------------------------+----------------------------------+

   GetCapexInfo Common Information:
   GDS ID Vector:
    +----------------------------------+----------------------------------+
    | (08) GDS length (4 + sum of length of all CVs)                      |
    +----------------------------------+----------------------------------+
    | (0a) GetCapexInfo GDS ID (0x???? - e.g., 0x1525)                    |
    +----------------------------------+----------------------------------+

 Version Number is set to 0x32 for all DLSw UDP OUI frames that comply with
 RFC 1795 and enhancements.

 Header Length is set to the length of the standard part of the DLSw UDP OUI
 frame format (8 bytes).

 Message Length is set to 0.

 The OUI field is set to all zeros to indicate a DLSw UDP OUI format frame
 that is architected and approved by the AIW as a standard frame format.

 Message type is set to 0x01 - the value for a Discovery/Resource Advertisement
 UDP frames.

 6.1 Capabilities Exchange Info SSP message DLSw UDP frame format

     The Capabilities Exchange Info frame is a mandatory frame.
 This frame is sent via unicast in response to a GetCapexInfo frame.

     The format of the Capabilities Exchange Info frame is identical
 to the format of the RFC 1795 Capabilities Exchange Request SSP message
 with the following exceptions:

 1) GDS ID is change from 0x1520 to 0x???? (e.g. 0x1526) to make it easier
 for a common parse routine to know this is a UDP capex and not a TCP capex.

 2) This frame is not responded to with a Positive or Negative Capabilities
 Exchange Response since no action can be taken on the response.

 3) The Capabilities Exchange between partners is independent in each
 direction.  That is, DLSwA may request capabilities of DLSwB (and DLSwB must
 respond), but DLSwB might not request capabilities of DLSwA.

     The following change is required for both the TCP Capabilities Exchange
 Request SSP message and the UDP Capabilities Exchange Info message:

 1) New Capex Correlator Control Vector.

 6.1.1 New Capabilities Exchange Request Control Vectors

     To make it easy to distinguish between TCP Capabilities Exchange Request
 frames and UDP Capabilities Exchange Info frames by a common parser, new
 GDS Ids are used:

     0x???? (e.g. 0x1526) - UDP Capabilities Exchange Info

     The following control vectors are added to the list of capabilities
 exchange control vectors.

 6.1.1.1 Capex Correlator Control Vector

     The Capex Correlator field must match the Capex Correlator field
 in the AreYouThere or IAmHere frames that a DLSw sends.

     Since UDP is an unreliable transport, the UDP Capabilities Exchange
 Info frame may have to be resent.  The receiver may need to determine whether
 a received UDP Capabilities Exchange is a duplicate or a new one.
 Also, it would be nice to know whether a Capabilities Exchange Request
 received during TCP session establishment is different from the last
 UDP Capabilities Exchange Info frame processed.

     The correlator control vector is added to serve this purpose.  The
 sending DLSw partner chooses a random number for this correlator value
 and sends it in its initial IAmHere frame.  The same value is sent in each
 Capabilities Exchange Info frame.  If the capabilities are changed, then a
 new correlator is chosen and all subsequent IAmHere and Capabilities
 Exchange Info frames contain the new correlator.
 correlator.

     It is important to note that the correlator value should not be
 initialized to the same value (1, for example) each time DLSw is started.
 If each time a DLSw partner is restarted, it sends a Capabilities Exchange
 Info frame with a correlator of the same value (1, for example), it is
 impossible for the receiving DLSw partners to determine whether the
 capabilities have changed or not.  The value should be initialized to a
 random number (perhaps date/time value).  After the initial capabilities
 are sent, a change in the capabilities can be indicated by incrementing
 the capex correlator (a random number does not need to be chosen with
 each change).

     The format of the Capex Correlator control vector is:

     Byte(s)    Description
    ---------  ------------------------------------------------
       0        Length, in binary, of the Capex Correlator CV
                It should always be 6.

       1        Type:   0x8D

      2-5       Capex Correlator
                A number representing the current capabilities.
                The number should initially be a random number (time/date).
                It should remain the same until the capabilities change,
                 and then it must change.

 6.2 Capabilities Exchange Details

     Following is a detailed discussion of the modifications to the
 existing RFC 1795 capabilities exchange.  It parallels closely the RFC 1795
 Capabilities Exchange Format/Protocol section.

     There is no proposed change to the Capabilities Exchange Request overall
 format.

 6.2.1 Control Vector Id Range

     The following new control vectors are proposed.

          Vector Description                               Hex Value

          Capex Correlator Control Vector                  0x8D

 6.2.2 Control Vector Order and Continuity

     The Capex Correlator control vector is required to be the
 fifth control vector of TCP Initial Capabilities Exchange Requests.
 For backward compatibility, if the Capex Correlator control vector is not
 present, the receiver should process the frame as though it has received
 a new (different) capex correlator.

 6.2.3 TCP Initial Capabilities Exchange

     The TCP initial capabilities exchange still refers to the capabilities
 exchange that occurs immediately after the TCP/IP session is established.

     The only change to the TCP initial capabilities exchange request is
 the new Capex Correlator control vector.  It is required if supporting
 this proposal.

 6.2.4 TCP Run-Time Capabilities Exchange

     The TCP run-time capabilities exchange still refers to the capabilities
 exchange that occurs after the TCP/IP session is established and after the
 initial capabilities exchange.

     The only change to the TCP run-time capabilities exchange request is
 the new Capex Correlator control vector.  It is required if supporting
 this proposal.

 6.2.5 UDP Capabilities Exchange

     The UDP capabilities exchange refers to the capabilities exchange
 that occurs before the TCP/IP session is established.  The capabilities
 exchange frames are sent via unicast UDP.

     All capabilities exchange control vectors are allowed to be present
 in the UDP Capabilities Exchange Info frame.  This includes the new
 Capex Correlator control vector.

     The following control vectors are required in the UDP Capabilities
 Exchange Info frame:

     Vendor ID control vector
     DLSw Version control vector
     Supported SAP List control vector
     Capex Correlator control vector.

     Note that this frame is sent in response to a UDP GetCapexInfo
 frame.  No response is sent in receipt of this frame.

 7.0 Resource Advertisement Details

 7.1 Overview

     Each v1r2 compliant DLSw has two obligations with respect to DLSw
 resource advertisement:

 1) Maintain an accurate capex correlator field.  This field should remain
 the same until the capabilities change or the DLSw function restarts - then
 the value must change to indicate a capabilities change.

 2) A DLSw must respond to a GetCapexInfo frame with a CapexExchangeInfo frame.

     A DLSw is NOT obligated to do any of the following:

 1) Send a GetCapexInfo frame.

 3) Maintain any information about DLSw partners having sent GetCapexInfo
 frames.

     Since the GetCapexInfo frame is not in the SSP message format, it may
 not be sent as a TCP frame.

 8.0 Basic Discovery / Resource Advertisement flows

 In the following flows, assume that DLSwA, DLSwB, and DLSwC all v1r2 compliant.
 Also assume that DLSwA and DLSwB are interested in DLSw partner discovery
 and resource advertisement, but that DLSwC is not.

 Example DLSwB bring-up flow (assume DLSwA and DLSwC already up):

  DLSwA                          DLSwB                          DLSwC
 -------                        -------                        -------

          (multicast) AreYouThere     AreYouThere (multicast)
      <---------------------------   --------------------------->

                (unicast) IAmHere     IAmHere (unicast)
      --------------------------->   <---------------------------

           (unicast) GetCapexInfo     GetCapexInfo (unicast)
      <---------------------------   --------------------------->

      (unicast) CapexExchangeInfo     CapexExchangeInfo (unicast)
      --------------------------->   <---------------------------

     The sender of the GetCapexInfo frame retries sending the frame
 periodically until it receives the CapexExchangeInfo frame.

     Each time a GetCapexInfo is received, it must be responded to
 with a CapexExchangeInfo frame.  The CapexExchangeInfo frame is not
 retried.

     Similarly, the sender of the AreYouThere frame retries sending the
 frame periodically (relatively short period) until it feels it has
 received most IAmHere responses (implementation choice).  The IAmHere
 frame is not retried.

 Example DLSwB periodic flow (after x minutes):

  DLSwA                          DLSwB                          DLSwC
 -------                        -------                        -------

          (multicast) AreYouThere     AreYouThere (multicast)
      <---------------------------   --------------------------->

                (unicast) IAmHere     IAmHere (unicast)
      --------------------------->   <---------------------------

                     If capex corr. different ...
           (unicast) GetCapexInfo     GetCapexInfo (unicast)
      <---------------------------   --------------------------->

      (unicast) CapexExchangeInfo     CapexExchangeInfo (unicast)
      --------------------------->   <---------------------------

     If a DLSw is interested in making sure its capabilities are
 up-to-date, it can periodically multicast an AreYouThere frame on
 all of its configured write multicast IP addresses.

     Upon receipt of the IAmHere frame, the Capex Correlator field
 in the frame is examined.  If it is different than the last saved value
 of this field for this partner, then the DLSw can send a GetCapexInfo
 frame to obtain the new information.

 Example DLSwC periodic flow (after x minutes):

  DLSwA                          DLSwB                          DLSwC
 -------                        -------                        -------

     Since DLSwC is not interested in partner discovery or resources,
      it is not likely that DLSw will send anything periodically.

 Example DLSwB configuration change:

  DLSwA                          DLSwB                          DLSwC
 -------                        -------                        -------
   (multicast or unicast) IAmHere     IAmHere (multicast or unicast)
      <---------------------------   ---------------------------> ignore

 If capex corr. different ...
           (unicast) GetCapexInfo
      --------------------------->

      (unicast) CapexExchangeInfo
      <---------------------------

     If a change is made to the capabilities, a DLSw box may multicast or
 unicast an IAmHere frame to notify DLSws of the change.  This frame need
 not be retried.  If it is dropped, DLSw partners that care will periodically
 send an AreYouThere to determine if capabilities have changed.  But there
 is be no harm in an implementation retrying this frame if it chooses.

     Upon receipt of the IAmHere frame, the Capex Correlator field
 in the frame is examined.  If it is different than the last saved value
 of this field for this partner, then the DLSw can send a GetCapexInfo
 frame to obtain the new information.

 9.0 Issues Not Incorporated

     The following issues have been considered and purposely not incorporated
 in this proposal.

 9.1 Notification of Removal of Multicast Address Change

     If a DLSw removes a read multicast address from its configuration,
 it has no way of sending to those DLSw's writing to the multicast address
 to notify them of the change.  DLSws writing to a multicast address do not
 necessarily read from it.

     Since it is possible to periodically send an AreYouThere to all DLSws
 to force a response, there is a way to determine that a DLSw no longer supports
 a read multicast address.  So no further support will be added.

 9.2 Unique Capabilities per Read Multicast Address

     To be ultimately flexible, the architecture could be expanded to allow
 DLSws to have a unique SAP list, NetBIOS name list, and MAC address list
 for each read multicast address and communicate this to each DLSw partner
 via capabilities exchange.

     In this proposal, the GetCapexInfo and the CapexExchangeInfo frames
 are sent via unicast UDP between individual IP addresses.  The capabilities
 are therefore associated with the DLSw partner and NOT with a particular
 multicast IP address for the partner.

     To add this flexibility to the CapexExchangeInfo frame would make it
 potentially huge.  So, unless there is a strong requirement for this ability,
 it is not architected.